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ABSTRACT 



Information systems executives within Department of Defense (DoD) activities are 
being challenged to develop innovative ways in which information technology can 
contribute to the streamlining of DoD organizations. Software reuse is a key strategy in 
developing information systems that will meet the future needs of DoD organizations. 
This thesis examines the concepts, and issues relating to the creation of a clearinghouse 
to facilitate and promote software reuse. Specifically it studies the Defense Software 
Repository System (DSRS), a DoD-wide version of the Army Reusable Ada Products for 
Information Systems Development (RAPID) effort. 
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I. SOFTWARE REUSE 



A. INTRODUCTION 

This thesis is part of a larger study sponsored by the Director of Defense 
Information (DDI) in which a series of case studies are being conducted to focus on the 
sound practices of MIS implementation in DoD. This particular case study examines the 
concept of software reuse and focuses on the DoD Defense Software Repository System 
(DSRS) initiative. DSRS is a DoD version of the Army’s Reusable Ada Products for 
Information Systems Development, and their methodology for software reuse. It will 
also identify critical success factors in implementing a DoD-wide policy on code reuse. 

B. PURPOSE OF RESEARCH 

The DoD Corporate Information Management (CIM) initiative promotes the use of 
Information Technology to improve business processes and the management of 
information resources. Software reuse has been identified by the Office of Defense 
Information as a key strategy intended to help DoD respond to variable threats in a 
rapidly changing environment with less resources. The integration of software reuse 
practices into lifecycle development of DoD systems will be a critical factor in achieving 
significant reduction in the amount of time required to develop complex systems. 
Equally important is the anticipated increase in system reliability and decrease in dollars 
spent for systems maintenance following implementation. The DSRS goal is to obtain 
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general purpose, adaptable software components that have maximum potential for reuse. 
They have established procedures and guidelines to certify reusable software components. 

C. RESEARCH METHODOLOGY 

This thesis is a case study that reviews recent literature on software reuse, conducts 
on site field interviews with CIM, RAPID, and DSRS personnel, and derives lessons 
learned from the RAPID/DSRS effort achieved to date. 

This study focuses on the RAPID/DSRS effort and the methodology for software 
reuse. RAPID/DSRS provides a comprehensive and structured framework for software 
reuse that could be of potential benefit to all users. Procedures to certify reusable 
software components proposed by RAPID will also be discussed. 

D. RESULTS OF RESEARCH 

The results of this research, and all references are contained in the Appendix. 
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I. Executive Summary 



To be successful in meeting the strategic challenges of today’s rapidly changing 
world, Information Technology managers must become proficient at doing more with 
less. Information has become a strategic resource for many organizations. To manage 
it, development activities are asked to deliver more software, more quickly and with 
lower fault tolerances than ever before. As the demand for new software steadily 
increases, so does the demand for supporting assets to maintain the system. In this 
environment of fiscal austerity. Program Managers are facing these accelerating 
requirements with budgets that remain stagnant or even dwindle from year to year. 

Software reuse can make a substantial contribution towards an organization’s 
efficiency and effectiveness in satisfying these requirements. Experts estimate that as 
much as half the code written for information systems is reusable in other development 
efforts. In the Department of Defense (DoD), where expenditures for administrative 
systems will approach 5 billion dollars this year, the potential savings generated through 
a comprehensive reuse program are staggering. 

The Army recognized the potential for returns on an investment in reuse and 
initiated the Reusable Ada Products for Information System Development (RAPID) 
program in 1987. Their approach centered on a library of reusable software components 
made available to software development teams. Software modules that satisfactorily 
completed a quality review were categorized and loaded to the repository. Users could 
then browse library assets selecting those modules that satisfied new development 
requirements. 

RAPID’S most significantly contributed to the reuse effort by establishing an 
infrastructure (i.e. the repository framework, cataloging systems retrieval systems, etc.). 
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for implementing a reuse methodology. DoD, committed to the concept of reuse and its 
potential savings adopted the RAPID Program as its own and established the Defense 
Software Repository System (DSRS) in 1991. The DSRS now supports users in all 
branches of the service providing a repository for contributions and distribution of 
software components. 

Though the application of a reuse technology in DoD is stUl in its early stages of 
growth, the experience of both RAPID and the DSRS provide some valuable insights: 



The concept of a central clearinghouse to process the intake and distribution of 
software is critical to the success of a DoD-wide initiative. 

Use of such a clearinghouse can provide substantial increases in development 
productivity. 

To enhance user confidence and the perpetuation of the reuse approach, 
repository supervisors must ensure only quality components are admitted to the 
library. 

Utilization of the clearinghouse could be significantly enhanced through 
the introduction of a DoD-wide incentive program. 
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II. Software Reuse: Doing More With Less 



Reuse of prior work is certainly not a new concept. When electrical engineers 
set out to develop a new circuit board, they often reuse pre-fabricated integrated circuits, 
made available to them through technical catalogs, to accelerate the development process. 
Likewise, corporate executives rely heavily on standard text documents to prepare legal 
and business documents. In the software environment, with billions of lines of codes and 
thousands of implemented information systems, existing software modules could be 
recycled to avoid the exorbitant costs of "re-inventing the wheel". 

Software reuse can be defined as the application of one or more previously 
developed software component(s) to a new system or to an expansion of an existing 
system. Often times, a significant portion of almost any new program contains logic that 
essentially duplicates the code found in other programs. Software developers for large 
organizations are just beginning to appreciate the potential benefits of reuse and are now 
seriously integrating reuse practices into the software development process. 



A. Beyond Code Reuse 

To date, efforts to reuse software have been primarily focused at the code level. 
Code reuse is the simplest form of reuse. A reusable code component consists of 
functions, procedures, or packages. Once developed, this component is tested, certified, 
and stored in a repository so that it can be accessed by programmers for new software 
development projects. 

Savings associated with code reuse can be realized in two ways: (a) each time 
a portion of code is reused, resources otherwise devoted to coding can be saved; (b) 
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further savings are also realized in the testing phase. In general, the "payoff for reusing 
a chunk of code is directly proportional to the size of the chunk. 

As the size of the code segment increases, it becomes more difficult for the 
programmer to identify a good match with specified functions. A large segment of code 
usually offers many functionalities. However, the greater the functionalities embodied 
in the new segment, the more difficult it is for the developer to succinctly describe the 
functional specifications of that segment. Larger components also tend to be more 
specialized or idiosyncratic and are therefore less likely to be compatible with a given 
set of requirements specifications. 

Reuse at the analysis and design level implies that the developer must ignore 
coding details, and focus on the computational intent of larger chunks of code that 
compose the system. Instead of looking at the coding style (e.g., the date/calendar code 
segment), the developer should examine how functional structures and specifications 
(i.e., date and calendar functions) are used in the context of the application. Reusable 
components at higher levels include logical data models, functional descriptions and 
diagrams (e.g., data flow diagrams or entity relationship diagrams).’ Although 
component reuse at the code level is better understood and by far the most prevalent 
form of reuse at other levels, one can witness an acceleration in the reuse of the other 
types of software components. 

For a given organization, there tends to be a family of application software that 
shares some common design characteristics. If these similar software design components 
could be reused, the developer would be free to concentrate on implementation of the 
unique functionalities of the software. Since design does not yet contain detailed 
decisions for implementation, a component’s potential for reuse is greater.^ Reusable 
design should provide pointers to the appropriate pieces of reusable code, reusable test 



‘ Neider, 1987 
^ Lenz, 1987 
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cases, and documentation. As a result, design reusability tends to provide much higher 
leverage than simply reusing code.^ 

Technically, existing software can be reused in a variety of ways. The spectrum 
includes sharing of code, algorithms, routines in application families, and subsystems.^ 
Reuse can be applied to all phases of the software development life-cycle, including: 

• Requirements specifications 

• High-level design 

• Detailed design 

• Coding and unit testing 

• Integrating testing 

• Documentation 

• Maintenance 

B. Desirable Characteristics of a Reusable Software Component 



Reusable Software Components (RSCs) can be extracted from public domain 
software, commercial off-the-shelf software, contractors, and government sources. A 
desirable reusable software component should include the following characteristics: 

• Flexibility: The developer should be able to adapt/modify the RSCs to fit in with 
the overall architecture of the software to be built. The smaller the component 
in terms of functionality, the more flexible it is but the less functionality it 
provides. 

• Expandability: The developer should be able to tailor RSCs to specific 
requirements that might surface well after initial requirements were defined. 



^ Biggerstaff and Lubars, 1991 
“ Lenz, 1987 
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Portability: The RSCs should be able to op>erate under multiple operating 
environments (physical hardware, op>erating systems, and runtime environments) 

Language Independence: The components above the implementation level should 
be programming language independent so that they are reusable in any 
programming language environment. 



C. Productivity Gains with Reuse 

Software reuse provides a number of benefits. Reusing software should help the 

information systems developer: 

• Improve software development productivity: Software reusability is viewed widely 
as a major opportunity for improving software productivity.^ At industry’s 
present rate of growth, a 20% improvement in productivity is projected to result 
in a savings of $45 billion in 1995 for the U.S. alone.^ 

• Achieve shorter development time: When a developer is able to reuse previously 
generated software in a new application, he/she frees up assets that can be 
devoted instead to development of the system’s unique modules. The savings in 
time- and resources translates to a development environment that is more 
responsive to the requirements of a dynamic world. 

• Increase software reliability: Preexisting software, if it has been employed to any 
extent, has already been field tested and fme tuned. This offers the opportunity 
of deploying modules whose expected error rate is significantly lower than that 
of a newly developed module. 

• Ensure enhanced maintainability: Reuse of well-structured and well-documented 
software will also lead to improved maintainability and portability in that 
alterations will be required only on the source component located in the central 
repository. With studies indicating a significant number of companies spending 
between 60 and 80 percent of their software dollars on maintenance, ’ this area 
may well generate the most significant dollar savings. 



’ Biggerstaff and Richer, 1987 
" Boehm, 1987 

’ Biggerstaff and Lubars, 1991 
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) Software reusability is now recognized as a major opportunity for improving 

, software productivity. Software costs were estimated in 1990 to be $125 billion for the 
U.S. alone. With such a magnitude in software costs, even a modest improvement 
thourgh reuse can translate into tremendous savings. 
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in. A Clearinghouse for Software Reuse 



A. Toward the Concept of a Clearinghouse for Reuse 

To effectively reuse software, RSC donors and recipients must incur non-trivial 
technical and administrative overheads. They need a central organization, say, a 
clearinghouse, to relieve them of these overhead costs. It is through the clearinghouse 
that the interactions between the users and donors can be assured. 



1. The RSC Donor-Recipient Cycle 

In many instances, an RSC will come from existing systems or systems currently 
under development. For an RSC to be reusable beyond its development site, it is 
important to distinguish the point of view of the donor from that of the recipient. A 
donor is one who identifies reusability of an RSC, develops the RSC that satisfies 
reusability specifications, and makes the RSC available in a library or repository. A 
recipient is a developer who reviews RSC available in the library and selects those that 
most closely support his requirements. Mechanisms for implementation as well as issues 
involving incentives or technical problems, for example, will vary depending on the 
orientation as donor or recipient. 



a. Mechanism for Creating RSCs — the Donor's Perspective 

When a program manager participates in the process of contributing software, he 
assumes a donor’s perspective to reuse. He needs to identify and describe the 
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functionalities embedded in candidate RSCs. He also needs to carry out testing and 
documentation for those RSCs. 

A willing donor is one who is able to look beyond the immediate costs both in 
time and resources and commit to the long-range reuse strategy. To alleviate this effort, 
help from external source(s) is usually required unless the donor himself is in the 
business of software production and can reap the benefits of donated RSCs. 



b. Mechanism for Retrieving and Using an RSC — the User’s Perspective 

In contrast to the donor’s orientation where benefits from reuse are anticipated at 
some point in the future, RSC users realize an immediate advantage. To maximize the 
benefits of reuse, the user must possess skills and experience to: 

• Find RSCs (cataloging, search and retrieval mechanisms) 

• Understand RSCs’ characteristics 

• Adapt RSCs to his functional requirements 

From the user’s perspective, reuse wUl be attractive only if the overall effort to 
reuse a piece of software is less than the effort required to create it from scratch. If a 
user has to invest an unacceptable amount of time in searching and evaluating repository 
components, he will likely opt to develop the component himself instead. Thus, it is 
critical that an RSC library be made available to the users. This repository has to 
contain RSCs that correspond to the user’s requirements and needs. 



2. Motivations for a Clearinghouse 

As discussed in the previous section, reuse is an appealing concept but its 
implementation requires a sustained economic and managerial effort that goes beyond that 
of an individual participating software developers. The creation of a clearinghouse for 
reuse is required to assume and direct much of this effort, provide broader visibility of 
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useful software, promote standardization, and yield greater savings of maintenance 
dollars. 

a. Economic Incentive 

Before software reuse can begin to pay off, an up-front investment is required. 
There will generally be costs involved in the preparation of the software prior to its 
induction into the library. Whether software is written for future reuse or taken from 
somewhere else, it requires formatting, testing, and documentation. Providing untested 
and undocumented RSCs is counterproductive. If the user needs to perform significant 
modifications to adapt the component, the benefit of reuse may be lost. 

In the short run, management of organizations that desire to donate software 
cannot be expected to support up-front costs for making RSCs. The fear that reusability 
will lead to reduction in their budget and staff is also a source of resistance among 
managers and programmers.* Programmers are often penalized for taking the extra time 
to make software reusable. 

It is thus important that a clearinghouse for reuse be built to absorb the cost of 
establishing RSCs and — more importantly — maintaining a library of reusable software 
components. The cost of a library depends on its size and the tools used to populate, 
organize, access, and maintain RSCs. 

A clearinghouse for reusable software has significant advantages. With its 
resources dedicated to reuse, the clearinghouse can assume the essential and unique role 
of networking multiple libraries owned by various participating organizations developing 
similar software, thus yielding economies of scale. It can also develop its own RSCs if 
they cannot be found anywhere else. The economics of software reuse vary significantly 



* Wong, 1987 
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with the problem domain and the development technology employed within an 
organization.’ 

It is expected that the cost savings of reusing thoroughly tested and documented 
software will be even more significant in the long-run. However, the long-term benefits 
of reuse are often hampered by short-sightedness of many RSC donors and users. It is 
the mission of the clearinghouse to correct this short-term perspective, and play an active 
role in reconciling conflicting interests between individual RSC donors and recipients. 



b. Managerial Incentive 

Researchers tend to agree that the lack of a clear reuse strategy has been one of 
the major factors inhibiting widespread software reusability." The absence of an 
appropriate high-level reuse strategy results in project managers and programmers being 
unmotivated to reuse software. Reuse will not happen by itself: it needs to be promoted 
with incentives. 

Top management of participating organizations must understand management’s 
critical role in addressing non-technical issues such as legal and proprietary rights, 
compensation for RSC developers, and internal cost apportionment methods for 
purchasing reusable components associated with software reuse. Contract issues 
concerning ownership and rights to the developed software arise. Contracts must be 



’ Barnes, 1987 

Who pays the added development cost involved in designing the software for reuse? Ideally, the 
organization that profits from the reuse should pay for it, but it does not always work this way. For 
example, a contractor might be asked to make his software reusable with little recognition of the added 
cost required. As a consequence, he earns a lower profit. Furthermore, the software component could 
then be given to a competitor to be reused, thus allowing the competitor to capitalize on the initial 
contractor’s efforts. It can work in the contractor’s favor as well: the customer might pay an added cost 
for highly reusable software without realizing it, so that the contractor can reuse the software in his own 
future programs. 

" Biggerstaff and Richer, 1987 
Banker and Kaufman, 1990 
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tailored to meet the needs of both donors and users in order to provide an incentive for 
reuse. 

Management that invests in the development of a meaningful incentives program 
will enhance their organization’s chances of implementing a successful reuse 
I environment. For example, the National Aeronautics and Space Administration (NASA), 
in a move to encourage development of higher quality software by contractors, has 
instituted financial rewards for certain types of library resident routines. Developers are 
compensated forextracting software from the library instead of being paid solely by the 
quantity of new code they create. This provides the contractor with incentive to utilize 
the methodologies of reusable code.’^ 

GTE provides another example. GTE Data Services places major emphasis on 
incentives and has introduced a program that rewards authors, project managers, and 
reusers. Programmers receive both cash bonuses (when an asset was accepted into the 
repository) and royalties each time an asset is reused in a new application. Budget 
increases and promotions for project managers are directly linked to high percentage 
reuse in deliverables under their cognizance. GTE considers the incentive program a key 
factor in their reuse success which translates into an estimated savings of $1.5 million 
during the program’s first year of operation and a projection of $10 million by the end 
of the fifth year.’* 



B. Activities of the Clearinghouse 

The following are the main activities that the clearinghouse should perform on 
behalf on the reuse community: 



” Cashin, 1991 
Prieto-Diaz, 1987 
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1 . Defining Reusable Domains 



Since software comes from a variety of domains, there is a need to identify 
software components that share basic functionalities. This can be achieved by a process 
known as domain analysis. The purpose of domain analysis is to determine 
commonalities within the application domain, focusing on areas with the greatest potential 
for reuse and in greatest demand by future software developers. It is an iterative process 
involving an intense examination of the domain of interest.'* Without a well-performed 
domain analysis, RSCs cannot properly be identified. 



2. Searching for RSCs 

The search for RSCs is a non-trivial effort. Potential sources (e.g., existing 
governmental systems, public domain software, or commercial off-the-shelf software) 
have to be identified. Of particular concern during this component search is a donor’s 
reputation or track record for producing quality software. 



3. Certifying RSCs 

Certification refers to the process designed to solve and eliminate concerns 
programmers and managers have about using RSCs that originate from outside their own 
work. Such concerns include quality, maintainability, liability for defects, and 
testability. A certified RSC must function as it is intended to function. Evaluation is a 
very important part of the certification process. It begins as candidate RSCs are 
identified and continues through the remainder of the life cycle. Evaluation can eliminate 



Softech, RAPID Center Reusable Software Component Procedures, June 1990 



unsatisfactory components, identify re-engineering needs, produce documentation, and 
initiate essential metrics.'* 

4. Creating a User-Friendly Library 

A library system is needed for users to identify, retrieve, and use RSCs. 
Software selected for incorporation in the library must be integrated with other repository 
components via an identification scheme. The cataloging system implemented should be 
easy for the user to understand, and should provide alternative search patterns for the 
user to search for the perfect component. Lastly, the indexing system should be 
adaptable in the event that future components are not easily tailored to existing 
categories. 



5. Supporting RSC Users 

A productive reuse environment cannot be maintained without the confidence of 
the user. This confidence is achieved in several ways. Most notably, the RSC 
certification process contributes to this effort by ensuring both the quality and 
standardization of each component in the repository. Additionally, RSC users’ concerns 
and needs should be periodically surveyed to ensure efforts are continually focused on 
the needs of the customer. 

In summary, the implementation of a clearinghouse offers several advantages: 

• The clearinghouse can perform domain analysis over a broad range of 
applications, that will likely increase the accuracy of the domain model and its 
relevance for future application development. 



'* Metrics assist managers in measuring various things and allow engineers to apply predictive 
algorithms. Metrics include size, productivity, efficiency, and quality characteristics such as portability, 
maintainability, and reusability. Metrics also provide a prediction of problem areas and alternative 
solutions. 
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With its central position, the clearinghouse has the authority and expertise to 
enforce a strict reuse discipline. Certification procedures can be put in place to 
ensure uniform quality of RSCs. This directly influences user confidence in the 
clearinghouse. 

As the clearinghouse imposes a standardized reuse procedure, it offers the 
opportunity to serve a larger community. 
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rV. DSRS - A Clearinghouse for Software Reuse 



A.CIM and Reuse 

Launched in October 1989, the DoD Coiporate Information Management (CIM) initiative 
seeks to improve DoD business processes and the management of information resources. 
To achieve this goal, CIM is calling for functional interoperability between systems, 
standards compliance, and efficiency in software development through reliance on 
reusable software components, commercial off-the-shelf products, and computerized 
application development aids. 

CIM promotes two types of repositories; software reuse repository and hardware reuse 
repository.'’ The objectives of software reuse repository are to: 

•Develop a central DoD-wide RSC clearinghouse 

•Establish a data dictionary for DoD 

•Build an integrated repository for C3I software 

On the other hand, the hardware reuse repository seeks to: 

•Shorten acquisition cycle by leasing 

•Introduce a standard bus architecture for scalable processors 
•Provide for central technology renovation 
•Rationalize capacity and security management practices 
•Distribute capacity by means of survivable networks 

Software reuse is considered to be one of the key strategies intended to help DoD in 
responding to variable threats in a rapidly changing enviromnent with less resources. 

’’ Strassman, 1991 
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The Office of the Director of Defense Information set the following goals for software 
reuse:** 

• 100% reusable data with an infinite life for data definitions 

• More than 80% reusable code with more than 20 year life on software elements 

• 80/20 development/maintenance ratio 

• Technology asset life two to three times larger than the technology innovation 
cycle. 

The goal of implementing a DoD-wide repository of reusable components has 
culminated in the recent establishment of the Defense Software Repository Service 
(DSRS). Under the administration of the Center for Software Reuse Operations 
(CSRO),*’ the DSRS provides automated access to more than 1550 government or 
commercially owned/developed RSCs. This repository is available to all DoD, other 
government agencies, and authorized contractors. 

The design and implementation of DSRS is based on a pilot operation initiated by 
the Army’s "Reusable Ada Product for Information System Development (RAPID). This 
chapter reports some of the experiences gained by RAPID, and subsequently DSRS. 



B. RAPID - The Army’s Software Broker 
1 . History and Mission 

The Army recognized the tremendous potential of software reuse. It called for the 
establishment of a software reuse clearinghouse offering Army/DoD users a centralized 
repository of reuse components by initiating the RAPID project in 1987.^° 



Strassman, 1991 

” CSRO has been set up within the Defense Information System Agency’s Center for Informatio: 
Management. 

“ RAPID was located at the U.S. Army Information Systems Software Development Center 
Washington (SDC-W). 
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With Ada as the programming language mandated by Congress, RAPID sought 
to promote the reuse of Ada software to reduce the cost of system development and 
maintenance through the use of previously developed tested and implemented 
components. Ada is a programming language designed to facilitate reusability because 
its reusability guidelines are structured to include design for reuse, parameterization, and 
domain analysis.^* Ada code is portable in that code written anywhere is potentially 
reusable for another system. It is well suited to the integration of system components 
from multiple sources. 

RAPID defines its missions as follows: 

• Achieve the Department of Defense (DoD) initiative of reusable, maintainable, 
and reliable software 

• Develop, maintain, and administer a comprehensive reuse program 

• Lower software lifecycle costs by increasing productivity and quality. 

Initially intended for management information systems (e.g., financial, logistics, 
and personnel systems applications), RAPID expanded its domain to additional 
application areas (e.g., telecommunications). In 1991, it had more than 960 reusable 
components stored in a central repository available to all Army/DoD units. RAPID 
would then issue software to both DoD users and contractors working on DoD projects 
as government-furnished equipment (GFE). 



2. RAPID Implementation Plan 

RAPID was initiated at SDC-W as a pilot prototype reuse program in July 1987 
when the Phase I contract was awarded. This initial phase produced the foundation 
needed to provide a reusability program within SDC-W. Table 1 depicts the chronology 
of the phases of the RAPID project. 



Banker and Kaufman, 1990 
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RAPID PROJECT PHASES 



PHASE I: Design and Development (July 1987 - April 1989) 

• RAPID Center Concepts and Organization 

• Reuse Policies and Procedures 

• RAPID Center Library System 



PHASE n: Pilot Operation (May 1989 - December 1990) 

• Operate Active RAPID Center 

• Support SAC-W Customers 

• Policy and Procedure Refinement 

• Library Population 

• Training Program 

• Domain Analysis 



PHASE ni: Implementation (January 1991 - September 1991) 

• Expand to all ISEC Development Centers 

• Expand to Other Organizations 

• Continue Library Population and Enhancements 



PHASE IV: CIM Operation (October 1991 - October 1996) 

• Individual Service focused Support 

• Expand Domain Analysis Customers 

• Continue Library Population 



3. RAPED Staff Organization 

Under the supervision of a center manager, the RAPID staff is composed of 
technical consultants, systems analysts, software engineers, configuration management 
specialists, quality assurance personnel, administrative assistants, and librarians. The 
staffs mission is to encourage design methods and architectures that build from reusable 
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components. Systems analysts and software engineers provide vital support for RAPID’s 
role as a software clearinghouse while other positions, such as RAPID’s administrative 
assistants, are more heavily weighted towards user assistance or RSC cultivation. 

Support personnel for the program consisted of 16 government employees and 8 
contractor personnel. The following describes some specific positions of these staff 
members: 

a. The RAPID Manager: Continually monitors the success of the RAPED program 
and the results of specific operations. He keeps extensive reports that help evaluate the 
costs of the program as well as the savings to developers. 

b. Technical Consultants: Perform the domain analysis, attend design reviews, stay 
abreast of projects, advise project staffs, and assist the developer in identifying potential 
areas of reuse. They help search for RSCs, and provide guidance, support, and 
documentation to programmers. 

c. System Analysts and Software Engineers: Identify high-value RSCs that are to be 
added to the library. They evaluate, test, and document all RSCs before being added to 
the library. They also provide maintenance and enhancements to the RCL (Rapid Center 
Library) software system. 

d. Configuration Management Specialists: Ensure that all configuration activities are 
performed for each library component, including problem report tracking, controlling 
changes, and releasing new versions or enhancements. 

e. Quality Assurance Specialists: Ensure that all RSCs are of high quality through 
frequent reviews. They develop and administer testing as well as establish and enforce 
metrics. 

/. Administrative Assistants: Prepare all RAPED Center Library System reports and 
perform foUow-up interviews with the users. 

g. The Librarian: Maintains the RSC data base and performs normal operator 
functions. 
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4. RAPID Activities as a Clearinghouse 

a. Defining Reusable Domains 

For a clearinghouse to operate effectively, domain analysis must be performed. 
As a continuing process, it not only identifies components that may be reused, but also 
directs developers to areas where reuse emphasis should be placed so that new 
components can be found during post-deployment support. 

As part of the initial steps to establish RAPID, a high-level domain analysis was 
done in 1987 that covered management information systems. During the pUot operation, 
RAPID realized the need to support multiple domains. Therefore, policies, procedures, 
and guidelines were revised to extend their potential applicability beyond MIS. 

Object-oriented methods were adopted for domain analysis. As a standardized 
method, they proved to be effective in identifying reuse opportunities, and for grouping 
RSCs according to the level of abstraction or functional category. 



b. Searching for RSC Donors 

Once the reusable types of software components are identified through domain 
analysis, it must be determined where those components will come from. This is a 
responsibility of the RAPID engineers. These personnel would turn to a variety of 
sources to identify potential candidates including: 

• COTS Software 

• Government-owned Software 

• Public Domain Software 

Of the 960 RSCs currently in the repository, more than 780 have been developed 
commercially. Of the 170 government owned components, less than 30 were developed 
by the RAPID in-house engineers. 
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COTS software tends to be a more appealing source for several reasons. It is 
well-tested before release, and is often accompanied by substantial documentation. 
Typically, the software has been in use for a substantial period of time before it is 
identified as a candidate RSC. It is thus likely to be highly reliable. 

Roughly 85% of the RSCs in the Army repository are code. The remaining 
component types include such software as design components, documentation 
components, and functional specifications. Although originally conceived to house Ada 
code, the repository does contain RSCs written in other languages such as COBOL, C 
and FORTRAN. 



c. Certifying RSCs 

The certification process begins with a quality evaluation of the candidate RSC 
once it is identified. The evaluation process not only determines basic attributes such as 
the lines of code or number of packages but also estimates the reuse potential for the 
component. It also estimates the level of re-engineering needed to ensure quality 
standard. 

The certification includes testing on a variety of platforms. Re-engineering is not 
done for commercial off-the-shelf components whenever code changes may invalidate the 
license. COTS RSCs are entered into the RAPID Center library after the applicable 
RAPID Center documentation standards are met. 

The RAPID Center assigns a certification level as "the level of confidence" in the 
quality of the RSC; it ranges from level I to level V, as described below: 

Level I: Depository - No formal testing and documentation 

Level n: Reviewed - Some testing and documentation 

Level ni: Tested - Test Suites Validated and some documentation 

Level rV: Documented - Fully tested and documented; meets aU standards and 

guidelines 
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Level V; Secure - Currently not used 

Level V certification is reserved for future use to cover secure components in 
accordance with DoD CSC-STD-001-83, Trusted Computer System Evaluation Criteria. 
Policies and procedures for secure components will be developed whenever such RSC 
become available. 

Ideally, every component in the library would be tested and documented to the 
extent that a Level FV certification could be assigned. This has not been the case 
however, and a significant number of RSCs were accepted into the library at the lower 
certification levels. Of the more than 780 COTS components in the repository, only 285 
were certified at Level n, while the remaining components (COTS) were at Level IV. 
A similar breakout of government-owned components could not be obtained, but it was 
confirmed that a number of these components were certified at Levels I and II. 



d. Creating a User-Friendly Library 

RAPID uses a flexible faceted classification scheme to store and retrieve RSCs. 
Using the PC-based, menu-driven system, the user could initiate a search for an RSC by 
entering parameters or "facets" that describe the RSC. The nine facet classification 
descriptors listed below, allow the user substantial control over the repository search: 

• Component Type 

• Language 

• Unit Type 

• Function 

• Algorithm 

• Environment 

• Object 

• Data Representation 
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Certification Level 



To conduct a search, the Function, Language and Certification Level descriptors 
must be provided. The use of the other facet terms is optional. To enhance the search 
capability, the RAPID search mechanism also provided the user with a "thesaurus list" 
that helps identify facet terms (known as "synonym terms") that appeared to be 
comparable to the user’s description. The system also provided links (i.e., 
"Relationships") between RSCs so that the user can browse or extract related 
components. 

RAPID maintained RSC metrics on reusability, mcdntainability, reliability, 
portability, actual usage, and outstanding problem reports. Based on these metrics, the 
users could choose to rank components and select the most appropriate ones. 



e. Supporting the User 

User support and feedback is an essential aspect of clearinghouse activities. In 
addition to the assistance from its central office, RAPID offered a remote site program 
where its personnel spend a period of time at the user’s site to assist in establishing a 
local reuse repository infrastructure (e.g., reuse planning, hardware and software 
selection, RSC creation and population). 

Formal training was also part of RAPID’s support of the users. Programs have 
been developed at three levels; Executive, Management and Software Engineering. This 
training is available at both the Army Reuse Center and remote sites. 

The RAPID librarian solicited the RSC recipient’s feedback, approximately ninety 
days after the RSC extraction. The inquiry was intended to check whether or not the 
RSC was used or if any problem was encountered. The expectation was that such user 
feedback provided on a continuous basis would ultimately result in a more responsive 
library. Furthermore, this feedback would provide some clues in assessing the 
effectiveness as well as the costs of reuse. 
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C. DSRS — Toward a the DoD-wide Reuse Program 

The DoD surveyed software reuse efforts within the department and keyed on the 
Army’s RAPID (Reusable Ada Products for Information System Development) initiative. 
It was clear that this program, though stiU in its early stages of development, was buUt 
upon a methodology that closely aligned with DoD’s vision for the future regarding 
reuse, and its role in software development. Tapping on this positive learning 
experience, DoD established in 1991 the Defense Software Repository Service (DSRS). 



1 . The DoD Reuse Organizational Structure 

As described in Figure 1, DSRS is under the management and supervision of the 
Center for Software Reuse Operations (CSRO). CSRO is a component of the Defense 
Information Systems Agency (DISA). DSRS is a distributed operation with four remote 
centers supporting DoD services and the Defense Logistics Agency DSRS supports 
reuse efforts at remote centers, and ensures that these efforts are complementary and not 
duplicative. Predominantly staffed by contractor employees, 7 contract personnel fill 
bUlets in project management (1), engineering (4), configuration management (1), and 
librarian (1). Government personnel fill positions in customer service (1) and liaison 
with other government sites (1). 

2. Current Status of the DSRS Effort 

DSRS has adopted as its core not only RAPID’ s library of RSCs (at the time 
about 840 components), but its infrastructure as well (i.e., classification/retrieval system, 
RSC certification methodology, etc.). At the same time, DSRS also accepted RSCs from 
previously established Navy and Air Force repositories. To date, DSRS more than 1550 



“ The reuse remote centers are located at the following sites: Army Reuse Center is located in th 
Information Systems Command, Falls Church, VA; Navy Reuse Center at the Naval Computers an 
Telecommunications Station, Washington Navy Yard, D.C.; Air Force Reuse Center at the Standai 
Systems Center at Gunter Air Force Base, Ala.; Marine Corps Reuse Center at the Development Centei 
Quantico, Va. 
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CIM Reuse Organization 





On site Reuse Support 



Fig 1: CIM Reuse Organization 



components comprising over two million lines of code. RSCs are composed of 
communications packages, graphics programs, man-machine interfaces, Ada bindings, 
data structures, and Ada development tools. 

DSRS operates on a MicroVax 4000-300 running VMS operating system, 
Users can access DSRS from a terminal with VTIOO emulation through dial-up modem 
or via the Defense Data Network (DDN), although full networking capability via DDN 
is not expected until January 1993. Currently, when a user searches for an RSC, he has 
to access not only the DSRS central repository but also the ones located at the services. 
It is planned that all repositories will be interconnected to form an integrated DSRS 
repository by the end of 1993. 

^ The DSRS hardware platform is an upgrade of the RAPID configuration. 
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CSRO seeks to improve the user-friendliness of the DSRS interface. Currently, 
on-line help is made available to familiarize the user with the system. DSRS also has 
a feature called "Session Maintenance" that allows the users to keep track of his/her 
interaction with the repository system. A graphical user interface is being studied to 
replace the character-based and menu-driven interface. Finally, CSRO puts in place a 
Customer Assistance Office (CAO) to support users. 
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V. Lessons Learned 



A. A Clearinghouse is a Necessary Condition for Software Reuse in 
DoD 

DSRS has been established to respond to a widely recognized need for a centralize 
repository of reusable components in DoD. Given that donors and recipients are 
separated by organizational and geographical boundaries, there must be a marketplace 
to facilitate the exchange of RSCs. A DoD clearinghouse that allows networking of all 
of its remote sites is expected to further enhance RSC usability. As such, a 
clearinghouse contributes to the proliferation of software reuse. Without a clearinghouse 
bridging the gap between RSC donors and recipients, the software reuse effort would fall 
apart. 



B. A Clearinghouse is a Productivity Multiplier 

Early signs of success can already be observed, as evidenced by the 
implementation of the Retired Army Personnel System (RAPS) and the Air Force 
Logistics Material Automated Retrieval System n (LOGMARS). 

The Retired Army Personnel System (RAPS) is a report generator system that was 
a pilot study by developers and the Army Reuse Center. The goal from a reuse 
standpoint, was to integrate reusable software components into the systems development 
life-cycle and create a reusable system. Although the lines of code (LOC) in RAPS are 
not substantial, the fact is that reusable modules accounted for a significant percentage. 
Also of significance is the use of design components as well as implementation RSCs: 

• In the design phase four of ten system components were reused. 

• Implementation activity involved the reuse of 88 of 130 subunits. This accounted 
for 63.9% of LOC dedicated to implementation. 
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• Reuse of the testing packages for reused modules was also employed. 

The time savings calculated as a result of reuse in RAPS development amounted to more 
than 125 days. 

Similar success was obtained by the Air Force with its LOGMARS-II: 

• Released worldwide in February 92, LOGMARS-II is a PC-based inventory 
control system used in supply warehouses. The system consists of 18,600 lines 
of Ada code, of which 5,600 LOC were extracted from DSRS. An additional 
6,300 LOC came from existing in-house modules. 

• Also developed was a bar-coded label printing subsystem used for warehouse 
material and benchstock. Two modules consisting of over 2,500 LOC (28% of 
total system code) were extracted from DSRS. Five other modules, including 
those for screens and forms generation, were reused from LOGMARS-n. 
Overall, 73% of the subsystem code consisted of reused code. 

As the utilization of the clearinghouse’s RSCs has started to show signs of 
success, it is expected that more RSCs will be demanded in the future. With a well- 
populated repository, the clearinghouse would serve as a productivity multiplier. 



C. The Clearinghouse Must Populate its Repository with Quality 
RSCs 

In response to the growing appreciation of reuse, RSCs are being inducted into 
the repository at a rapid pace. The clearinghouse must ensure that RSC quality is not 
compromised in the process. RSC users are reluctant to utilize components of uncertain 
quality developed by unknown sources. They would accept nothing but "error-free" 
RSCs. The clearinghouse must carefully weigh the benefits of accelerating the 
population growth of RSCs, against the potential damage that might be caused if users 
experience problems with RSCs. 
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D. High-Level DoD Management Must Provide Incentives for Reuse 

A fully functioning repository populated with pertinent components is a necessary 
but not sufficient condition to promote a successful reuse program. Some inducement 
to reuse software is required as weU. To carry the necessary weight and visibility, these 
incentives must be promulgated from the highest authority within DoD. 

While many DoD organizations^ involved in software reuse have recognized this 
issue, there is no policy regarding financial incentives. It is imperative that incentives 
research continue and these critical issues be resolved in order to implement a competent 
reuse strategy. 



^ CSRO recognizes the critical issue of reward, and is working closely with organizations such as 
he Joint Avionics Working Group (JIAWG), and the Ada Joint User’s Group (AdaJUG) both of which 
ire conducting extensive research on incentive issues. 
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Glossary of Terms 



ADA - Programming language that facilitates reuse. Ada is the primary programming 
language in the Department of Defense. 

ADAMAT - A static source code analyzer that produces 150+ metrics on the quality of 
Ada code as it pertains to reliability, maintainability, and portability. 

CASE (Computer Aided Software Engineering) - Collective resource to a family of 
software productivity tools. 

CODE REUSE - The most common form of software reuse in which source code is 
reused. 

DESIGN REUSE - Reuse of a type of reusable software component such as logical data 
models, functional descriptions, and diagrams. 

DOMAIN - A group or family of related systems that share a set of common capabilities 
and/or data. 

DOMAIN ANALYSIS - The thorough examination of a domain that produces a 
representation of the domain and identifies common domain characteristics, primary 
functions, and objects. 

FACETED CLASSIFICATION SCHEME - Components are classified by selecting the 
most appropriate terms from each facet to best describe the component. 

FOURTH GENERATION LANGUAGE - Programming language that uses high-level 
human-like instructions to retrieve and format data for inquiries and reports 

GRANULARITY - The size of the chunk of code. 

IMPLEMENTATION REUSE - Reuse of a type of reusable software component such 
as package specifications, package bodies, subsystems, and test suites. 

METRICS - Numeric measures that characterize RSCs. 

OBJECT-ORIENTED DESIGN - Method for generating reusable software components. 
It uses data types as the base for modularization and defining objects. 
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REPOSITORY - Storage area for reusable software component. 

REUSABLE SOFTWARE COMPONENT - Originally a source code component 
consisting of functions, procedures, or packages. Now it includes requirements, design, 
implementation, templates, and generic architectures. 

REUSABILITY - Ability for a software component to be reused. 
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